在零售行业干了快十年开发，我见过太多巡店系统在“信号死角”里翻车。
上周去华东一家便利店连锁客户做技术回访，区域督导老周跟我吐槽：他们原先用的巡店App，一进地下冷库或者郊县加盟店的楼梯间，页面直接白屏，巡店拍照传不上，台账写一半丢了。这不只是体验问题，是数据资产在流失。我们团队接手重构时，核心诉求就一句——让巡店动作在断网环境下和联网时一样可靠。
这背后的技术坑，外行看是个“缓存”，内行知道是一场端侧架构的硬仗。
先说离线缓存。很多人以为离线就是把接口数据存进SQLite，其实零售巡店的场景复杂得多。一次标准巡店，要拉取门店基础信息、陈列标准图、历史违规项、促销排期，还要支持现场拍照、语音备注、打分表单。我们放弃了传统的REST全量拉取，改成基于门店维度的增量快照（Snapshot Delta）：首次进店下载完整包，后续只同步该店变更项。存储层用Room加协程流，保证主线程零阻塞；图片走独立的文件沙盒 缩略图预生成，避免大图IO把UI拖死。
更关键的是“冲突域”的收窄。早年方案用全局时间戳对拍，结果两个督导改同一家店的不同货架，同步时互相覆盖。我们在本地给每个巡店任务建了操作日志树（Op-Log Tree），以“巡检项ID 时间戳 设备指纹”做复合主键，把冲突粒度从“门店”降到“字段”。这样即使离线八小时，回店连上WiFi，也能做行级合并，而不是粗暴后写覆盖。
同步策略才是真正的突破点。我们没用常驻心跳，那样太费电，零售督导一天跑十几家店，手机撑不住。自研的自适应同步引擎会监听系统网络变换和网络质量评分：在WiFi下跑全量回传 服务端校验；在4G弱信号时，只传文本和缩略图，原图延后到夜间门店闲置时走CDN边缘节点补传。服务端用Kafka做削峰，巡检数据先落本地MQ再异步入库，避免巡店晚高峰把数据库打挂。
还有一个容易忽略的细节：离线状态的“可信反馈”。我们让App在断网提交时，本地生成带数字签名的回执，督导立刻能看到“已存本地，待同步”，而不是转圈圈假装成功。这种确定感，一线的人最买账。
从开发视角看，手机扫码巡店App的这次离线缓存与同步重构，不是堆技术名词，而是把零售现场的“不确定性”用工程手段消化掉。当督导在冷库里扫完码、打完分、拍完照，手机往兜里一揣就走，背后那套端云协同的脏活累活，才是巡店数字化的真正底盘。
微信号：18581869297
